Fix x-spring-provide-args handling. Pass arguments to delegates. Use JavaParser. - #24071

Check if this issue is valid — if so, understand the root cause and fix it. At modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/SpringCodegen.java, line 1593:

<comment>When a provided parameter has a type-use annotation, this only clears annotations attached directly to `Parameter`, so the delegate still receives nested annotations. Remove annotations recursively from the cloned parameter type so delegate signatures honor the annotation-stripping behavior.</comment>

<file context>
@@ -1559,41 +1571,82 @@ public CodegenOperation fromOperation(String path, String httpMethod, Operation
                         formattedArgs.add(newArg);
+
+                        Parameter delegateParameter = parameter.clone();
+                        delegateParameter.getAnnotations().clear();
+                        formattedDelegateArgs.add(delegateParameter.toString());
+                        formattedArgNames.add(parameter.getNameAsString());
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At modules/openapi-generator/src/test/java/org/openapitools/codegen/java/spring/SpringCodegenTest.java, line 8591:

<comment>The four tests between `shouldPassXSpringProvideArgsToOverridableMethodWithApiInterfaceRequestMapping` and `shouldIncludeXSpringProvideArgsWithInterfaceOnlyWithoutDelegatePattern`, plus `shouldSeparatePageableAndXSpringProvideArgsInReactiveControllerImplementation`, replicate the same ~25-line setup (temp dir, `parseFlattenSpec`, `ClientOptInput`, `DefaultGenerator` flags, `generator.opts(input).generate()`) verbatim, and two of them inline byte-identical anonymous `SpringCodegen` subclasses. The class already has the `generateFromContract(String, String, Map<String, Object>, Consumer<CodegenConfigurator>)` helper that performs this exact setup and accepts additional properties (including `REQUEST_MAPPING_OPTION`, which SpringCodegen.processOpts reads via `convertPropertyToTypeAndWriteBack`), so only the `_api_controller_impl_` hook really needs the custom subclass. Extract one small static codegen factory and route the api-interface tests through `generateFromContract`; this also keeps the new tests consistent with the rest of the file.</comment>

<file context>
@@ -8585,6 +8587,308 @@ void schemaMappingWithNullableAllOfRendersNullableJavaProperty() throws IOExcept
     }
 
+    @Test
+    public void shouldPassXSpringProvideArgsToOverridableMethodWithApiInterfaceRequestMapping() throws IOException {
+        File output = Files.createTempDirectory("test").toFile().getCanonicalFile();
+        output.deleteOnExit();
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At modules/openapi-generator/src/test/java/org/openapitools/codegen/java/spring/SpringCodegenTest.java, line 8842:

<comment>This data-driven test for api_interface mode only asserts the call text in `FooApi.java` (`return findFoo(pageable, providedArg);` etc.) plus guard strings. It never verifies the `_findFoo` signature, the `@Parameter(hidden = true) @Size(...)` annotations, or the delegate method signature — the sibling test `shouldSeparatePageableAndXSpringProvideArgsForRequestContextAndReactiveCombinations` verifies the delegate signature via `expectedApiDelegateMethodSignature(...)` but has no api_interface row. So a regression in api_interface signature/ordering/annotation output would pass this test silently. Assert the delegate signature for each row, mirroring the sibling test.</comment>

<file context>
@@ -8585,6 +8587,308 @@ void schemaMappingWithNullableAllOfRendersNullableJavaProperty() throws IOExcept
+                        INCLUDE_HTTP_REQUEST_CONTEXT, Boolean.toString(includeHttpRequestContext)));
+
+        JavaFileAssert.assertThat(files.get("FooApi.java"))
+                .fileContains(expectedOverrideCall)
+                .fileDoesNotContain("findFoo(,", "servletRequestpageable", "exchangepageable");
+    }
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At modules/openapi-generator/src/test/java/org/openapitools/codegen/java/spring/SpringCodegenTest.java, line 8622:

<comment>This assertion hard-codes a double space (`default  ResponseEntity<Void> foo(...)`) into the expected output. The generated interface really does contain that double space: `api.mustache` renders the "Override this method" block as `{{#jdk8-default-interface}}default {{/jdk8-default-interface}} {{>responseType}}`, where the stray space after the section close produces two spaces between `default` and the return type — unlike the `_foo` method on the same interface (same test asserts single space) and the delegate template, both of which render single-spaced. Fix the template spacing (drop the space after `{{/jdk8-default-interface}}`) and assert the canonical `default ResponseEntity<Void>` form, so the test catches the formatting defect instead of pinning it.</comment>

<file context>
@@ -8585,6 +8587,308 @@ void schemaMappingWithNullableAllOfRendersNullableJavaProperty() throws IOExcept
+                .fileContains("default ResponseEntity<Void> _foo(")
+                .fileContains("@Parameter(hidden = true) @Size(max = 64) String providedArg")
+                .fileContains("return foo(providedArg);")
+                .fileContains("default  ResponseEntity<Void> foo(String providedArg)");
+    }
+
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/SpringCodegen.java, line 1610:

<comment>If one `x-spring-provide-args` list item contains several comma-separated parameters, only the first is used and the remaining ones are silently dropped. The removed regex loop iterated `matcher.find()` over the whole string and produced one entry per parameter, so existing specs that pack multiple declarations into a single list item generated all of them (previously without commas, i.e. broken Java, now silently missing). The JavaParser-based path parses the string as one method and returns only `getParameter(0)`, so the extra declarations vanish without any warning or generation error, producing code that fails to compile with an unrelated-looking message. Validate that exactly one parameter was parsed and fail loudly (or split on top-level commas) instead of silently discarding input.</comment>

<file context>
@@ -1559,41 +1571,82 @@ public CodegenOperation fromOperation(String path, String httpMethod, Operation
+        CompilationUnit compilationUnit = StaticJavaParser.parse(String.format(Locale.ROOT, "class Dummy { void method(%s) {} }", oneArg));
+        return compilationUnit.findFirst(MethodDeclaration.class)
+                .orElseThrow(() -> new IllegalArgumentException("Unable to parse x-spring-provide-args parameter: " + oneArg))
+                .getParameter(0);
+    }
+
</file context>